home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
iesg
/
iesg.93-03-08
< prev
next >
Wrap
Text File
|
1993-04-21
|
17KB
|
443 lines
IETF STEERING GROUP (IESG)
REPORT FROM THE IETF MEETING
March 8th, 1993
Reported by: Greg Vaudreuil, IESG Secretary
This report contains IESG meeting notes, positions and action items.
These minutes were compiled by the IETF Secretariat which is supported
by the National Science Foundation under Grant No. NCR 8820945.
For more information please contact the IESG Secretary.
iesg-secretary@cnri.reston.va.us.
ATTENDEES
---------
Almquist, Philip / Consultant
Crocker, Dave / SGI
Crocker, Steve / TIS
Coya, Steve / CNRI
Gross, Philip / ANS
Hinden, Robert / SUN
Hobby, Russ / UC-DAVIS
Huizer, Erik / SURFnet
Knowles, Stev / FTP Software
Stockman, Bernard / SUNET/NORDUnet
Vaudreuil, Greg / CNRI
IAB Liaison
Chapin, Lyman / BBN
Christian Huitema / INRIA
Regrets
Borman, David / Cray Research
Reynolds, Joyce / ISI
Piscitello, Dave/ Bellcore
AGENDA
------
1) Administrivia
o Role Call
o Bash the Agenda
o Approval of the Minutes
- February 22, 1993
- March 8th
2) Protocol Actions
o Path MTU Discovery <Draft>
o IESG Advice from Experience with Path
MTU Discovery <Informational RFC>
o RFC 1327 tutorial <informational RFC>
o IEEE 802.5 Token Ring MIB <Draft>
o IEEE 802.4 Token Bus MIB <historic>
3) Management Issues
o Query sent to SNMP Working Group members
o SNMP Security/v2
o Router Requirements
o The US Domain, Farnet, and NWnet
o MIBs in Waiting
4) Working Group Actions
o Authorization and Access Control (aac)
5) Tasked Items
o Summarize the New IP Discussions
o New IPLPDN charter & milestones
o Secure FTP
MINUTES
-------
1) Administriva
o Approval of the Minutes
Discussion and approval of the minutes of both the March 1st and the
February 22nd teleconferences was deferred.
o Next Meeting
The next IESG teleconference was scheduled for Thursday, March 18th,
from 11:30 to 1:30 ET.
2) Protocol Actions
o MTU Discovery
The IESG reviewed the MTU Discovery Protocol as documented in
RFC1191. This protocol is widely implemented and is in use in the
operational Internet. A known operational problem is documented in
a companion document "IESG Advice from Experience with Path MTU
Discovery". The IESG approved this protocol for elevation to Draft
Standard and the companion document was recommended for publication
as an Informational RFC.
ACTION: Vaudreuil -- Announce the IESG approval of the MTU Discovery
Protocol as a Draft Standard.
o RFC 1327 Tutorial
This document is a tutorial on the X.400 <=> RFC 822 mail gateway.
Consideration was deferred until the next IESG meeting to review the
document.
o Token Ring MIB
The IESG discussed the urgency of considering the Token Ring MIB in
the absence of a Network Management Area Director. This protocol
has been a proposed standard for over two years and requires review,
but there is not strong pressure to elevate it immediately. The
IESG agreed to put a review of this protocol on hold pending
appointment of a new Area Director.
o Token Bus MIB
The IESG agreed that the Token Bus MIB could be moved to Historic
without having an Network Management Area Director.
ACTION: Vaudreuil -- Send out a ballot to the IESG to move the Token
Bus MIB to Historic.
3) Management
o SNMP Working Group Query
Erik Huizer sent out a query to the SNMP Version 2 and SNMP Security
Working Groups soliciting comments on the process by which these
proposals were submitted and reviewed. Specific comments were made
about the steering group management, the split of security into a
separate working group, and the compressed timeline, but the
comments were generally positive and indicated that the current
process should continue. A full summary of this query is included
as an Appendix.
Until the SNMP working groups submit the protocols to the IESG,
there is no further action for the IESG.
o Working Group Management
Well defined procedures for working groups to follow will help
answer specific questions about the standardization process. Erik
Huizer has posted an initial document with these procedures and will
incorporate lessons learned from the SNMP Evolution process.
ACTION: Huizer - Revise the draft of the Working Group guidelines
document in light of the SNMP Evolution process and incorporating
revisions suggested by Gross and DCrocker.
o US Domain
Issues about the management of the .us domain were taken off the
agenda and will be discussed within the Operations Area. It is not
clear there are issues needing IESG attention.
o Router Requirements
The editor of the Router Requirements documents was contacted and
gave a brief status update. The documents are under significant
revision, including the splitting of the main document into four and
incorporating changes necessary due to the passing of time. There
are a few technical details still to work out and it is not expected
that this work will be concluded in the next few weeks. The IESG
explored options of posting the current documents again as Internet
Drafts but reached no firm conclusions about whether the documents
which are almost ready should be posted immediately or whether the
documents should all be posted as a set. Discussion will continue
at the next meeting.
o Many Mibs
There are several MIBs which have been submitted to the IESG for
consideration as Proposed Standard but for which the Area Director
review has not been completed. The IESG agreed that advancing these
MIBS can be put on hold until a new Network Management Area Director
is appointed.
4) Working Group Actions
o Authentication and Access Control (aac)
The charter was not received by the IESG and needs to be resent
before it can be considered.
ACTION: Vaudreuil -- Resent the aac charter to the IESG and IAB for
consideration as a Working Group.
5) Tasked Items
o New IP Status Check
The list of New IP contenders has risen to five with the inclusion
of Robert Ullmann's IPv7 proposal. The feedback from the IETF
suggests that the list of contenders should not be artificially
pruned, but that the proposals be evaluated based on some metric of
progress. The immediate question facing the IESG is the allocation
of presentation time at the March IETF meeting. Rather than give
time for open discussion, the IESG agreed that the presentations
should present specific information on the progress made since the
last meeting. This progress would include information such as new
specifications written, implementations tested, and Internet
integration and deployment examined. Dave Crocker notified the IESG
that the SIP and IPAE Working Groups should now be considered a
single effort.
ACTION: Knowles -- Query each of the New IP contenders for their
current status in anticipation of making presentation time allotments.
o IPLPDN
There is a lively discussion of the IPLPDN Working Group charter.
The negotiations between the Working Group and the IESG continue
over limiting the scope of the Charter.
o Secure FTP.
Preliminary inquiries indicate that Common Authentication
Technology may be the proper technology for securing FTP. It
appears that the application of CAT to FTP can be done by the CAT
Working Group.
ACTION: Hobby -- Direct the Secure FTP folks to the CAT Working Group
to explore the incorporation of CAT to FTP.
Appendix - Summary of Action Items Assigned
ACTION: Vaudreuil -- Announce the IESG approval of the MTU Discovery
Protocol as a Draft Standard.
ACTION: Vaudreuil -- Send out a ballot to the IESG to move the Token
Bus MIB to Historic.
ACTION: Huizer - Revise the draft of the Working Group guidelines
document in light of the SNMP Evolution process and incorporating
revisions suggested by Gross and DCrocker.
ACTION: Vaudreuil -- Resent the aac charter to the IESG and IAB for
consideration as a Working Group.
ACTION: Knowles -- Query each of the New IP contenders for their
current status in anticipation of making presentation time allotments.
ACTION: Hobby -- Direct the Secure FTP folks to the CAT Working Group
to explore the incorporation of CAT to FTP.
Appendix - Results of the SNMP Community Survey
IESG report on SNMPv2 Process Inquiry
Erik Huizer
10-March-1993
Introduction
------------
In the Network Management and Security Area of the IETF, two working
groups have been working hard to define a new and secure version of
SNMP, called SNMPv2. These Working groups are the SNMPv2 Working Group
and the SNMP Security Working Group. These WGs have by early 1993
produced 12 Internet Drafts, which they will soon submit to the IESG
for advancement to proposed standard status. Recently, from a variety
of channels and to more than one member, complaints have reached the
IESG which call into question the process by which SNMPv2 has
advanced. SNMP is too important and the persistence of background
discomfort too significant for the IESG to ignore. Therefore the IESG
found it necessary to establish if the complaints are unfounded or
not, with the intention of putting matters of the WG's process to
rest.
To achieve this the IESG through one of its uninvolved members (the
author) held an E-mail inquiry amongst the members of the Working
Groups, asking for their comments on the process followed in the
creation of the SNMPv2 documents. It must be stated that there have
been no official complaints made to the IESG, and as such this inquiry
is unprecedented, therefore the inquiry included a request for
comments on the inquiry itself.
This report summarises the results from the inquiry.
The Inquiry
-----------
The following text was send by E-mail to the
distribution lists of the two Working Groups on the 2nd March 1993:
"The SNMPv2 process is drawing near to a conclusion with the
submission of 12 documents to the IESG. The IESG is working to process
these documents as soon as possible.
Recently, from a variety of channels and to more than one member,
complaints have reached the IESG which call into question the process
by which SNMPv2 has advanced. The entire IETF is accountable for the
standards it produces, and the IESG is obliged to investigate these
complaints to determine whether the process has remained fair and open
throughout. The IESG realizes the importance of a broad acceptance of
SNMPv2 and finds it necessary to establish that the complaints are
unfounded. The IESG has charged me, a non-partisan in the NM area, to
approach the community most directly involved with SNMPv2 for input.
Therefore I send you this message, and ask each and everyone of you
who has comments on the process that led to the creation of SNMPv2 to
send me a PERSONAL note. It should present your candid and
confidential assessment of the chronology of events leading to the
request to advance SNMPv2 to proposed standard, from the original call
for contributions through the most recent postings to the mailing
list. Since it is equally important to the IESG to hear from those
who view the process as having succeeded as not, I urge you to
respond. Please rest assured that your correspondence will remain
entirely confidential; I will report back to the IESG in a summary
fashion.
The IESG does not wish this "process checkpoint" to further delay the
advancement of these standards. You thus have until monday 8 march 9
am EST to react. This will give me enough time to summarise before the
IESG meeting later that day.
So if you want to send me a personal note on this subject, do it now,
and make sure that it has the same subject line as above, preceded by
"re:".
I apologise to everyone who feels offended by this note, or by the
query. The IESG recognizes that requests of this nature are highly
unusual, and deeply regrets having to proceed in this fashion. Indeed,
if you find this action to be contrary to the best interests of the
community, the IESG is interested in this feedback as well. We are
trying to do what is best from the community, and taking the question
to the community seems to be our best alternative in this matter."
The inquiry was aimed at the process followed, and not at he technical
contents of the WGs ofr the documents produced. For comments on the
technical contents of documents the IESG will use the normal "Last
Call" mechanism. Therefore remarks regarding technical contents of the
documents in response to the inquiry have been ignored.
The response
------------
The WG on SNMP Security distribution list contained 258 entries at the
moment the inquiry was sent. The SNMPv2 distribution list contained
459 entries. Only 37 people responded to the inquiry before the
deadline, 27 of them have E-mail addresses that indicate a commercial
background.
By far the majority of the people who responded (84%) claimed to be
passive listeners. I.e. they were interested participants, but did not
contribute any new ideas, nor participated actively in discussions on
the WG lists.
Although it is impossible to draw a unanimous conclusion from the 37
responses, the following observations are supported by at least 75% of
the responding people:
1- On the whole the process leading to the 12 Internet Drafts has been
as fair as possible and not much different from other IETF WG
processes; The current set of documents is cetainly the best that
could have been produced in such a short time, and is believed to be
the only one to get the majority consensus from the WGs.
2- There has been too much haste in getting the SNMPv2 proposal out;
There was no need for the IESG and the Working Groups to set such a
sharp deadline (december 1992). This deadline, and the pressure it
created made various contributors feel that their proposals did not
get the proper attention. Especially a final WG meeting in March
(Columbus) would have been a good thing.
3- The WG chairs have acted correctly, and they have done a wonderfull
job of making sure that the documents were ready on time; All this
within the limited timeframe, and with little leeway to have lengthy
discussions on alternative proposals.
4- The authors of the original SMP documents should have been more
restrained in their reactions; It was suggested that the original
authors should not have been the editors of the final documents,
although this clearly would have delayed the WGs. The amount of work
put in by the authors is very much appreciated and they are generally
acknowledged as THE authorities with respect to SNMP. However, the
original SMP authors had too much of a headstart in thinking along the
proposed SNMPv2 lines. This made them react (too) fast to alternative
proposals, which thus gave the (false) impression of not being
considered seriously. The authors also repeatedly used the argument
that their proposal was supported by working implementations, while
the alternatives were not. This is not a proper argument to be used in
a working group when working on a new protocol.
5- The decision to split the work over two Working Groups was
unfortunate. The two IESG Area Directors appointed to the process
were either too involved, or not involved enough. This lead to
miscommunication between the WGs and the IESG.
6- There was no objection against, but also no real necessity for the
IESG to do this inquiry.
7- Due to time pressure the security aspects that have been introduced
did not get the necessary attention/discussion
8- The concept of a design team going off and preparing an initial
working document is applauded. However there should be regular
feedback from a design team into the WGs. The current situation where
the result of the design team was heralded into the world through
the press has been found very counter-productive.
The Conclusions and recommendations
-----------------------------------
The SNMPv2 documents have been produced according to the normal IETF
process with the two involved WGs operating much in the same way as
other Working Groups. If there are any remarks to be made about the
process they can be traced back to two main errors:
- The IESG has failed to manage the SNMPv2 process properly; The main
error being that the deadlines put onto the WGs were unnecessary
tight.
- The authors of the original SMP proposal have chosen an unfortunate
way of presenting their proposals 'out of the blue' and defending
them.
Despite these shortcomings the WG chairs, the authors and other WG
members succeeded in getting the documents ready within the agreed
deadlines. The "Last Call" mechanism will have to show whether there
are still technical issues unresolved that prohibit moving the
documents to Proposed Standard and reviewing the results of this
before moving them to Draft Standard.
The inquiry performed by the IESG was usefull although not perceived
to be necessary, and the amount of responses seems to confirm the
latter. The IESG should therefore in future refrain from these kind of
inquiries unless there are official complaints.